1. Field of the Invention
The present invention generally relates to the testing of integrated circuits, and more particularly to a computer system and process for testing an integrated circuit for compliance with its architectural design parameters.
2. Description of the Related Art
In the process of designing and manufacturing integrated circuit chips, it is important that the semiconductor manufacturing process contains a set of physical design rules for such parameters as the placement, wiring, and geometrical layout of the integrated circuit chip. Moreover, it is necessary that every chip manufactured in a particular process is checked and verified that it complies with the given design rules. Hence, protocols for design rules checking are provided to ensure that the geometric shapes of the circuits are placed in proper proximal distance from one another, because incorrect placements will lead to chip failure.
Specific design rule checks verify the shape and sizes of various circuit components that are diffused, deposited, or etched onto a chip. Additionally, design rules checking also verifies that the shapes are of the proper size, shape, and type, and furthermore, that the shapes are not placed so close together within the chip that they will not work. A conventional methodology for the design rules checking is a general purpose shapes processing program (GPSPP), that receives inputs from two files: runset and physical layout files. The runset file is a command language input file that instructs the processor executing the GPSPP how to perform the design rule checks. More specifically, the runset comprises several hundred individual checks.
When developing a design rule checking (DRC) runset for a semiconductor process, a set of layout testcases is required to verify functionality and accuracy. The task of creating testcases for DRC runsets exists across all organizations and companies that code checking runsets. The code for DRC is created based on a set of layout design rules or parameters for a particular semiconductor process. The code and testcases are both manually created. Additionally, the testcases contain shapes that represent a failing and passing condition for each rule specified in the semiconductor process. The testcases must be modified when design rule changes are made to the semiconductor process, however, modifying the testcases is a rather time consuming process.
A conventional generation and verification program called Shapediff, available from IBM Corporation, NY, USA, and disclosed in U.S. Pat. No. 6,063,132, the complete disclosure of which is herein incorporated by reference, uses the testcases to ensure that the DRC is checking properly. Shapediff summarizes the results of the DRC to show if there are any unexpected results. However, Shapediff needs to be run for every process type and the testcases need to be created for each variation on the process (for example on three metal levels instead of four; these are known as back end of the line (BEOL) metal stack options). Also, there is no guarantee that each design rule has been coded. Thus, while the Shapediff program and methodology is an extremely important and useful tool in design generation and verification, a new enhanced methodology is required to further improve on the conventional design rule checking systems.
Other conventional systems and processes teach generation and verification methodologies, such as U.S. Pat. No. 6,212,667 (teaches automatic generation of testcases to run against microarchitecture models); U.S. Pat. No. 5,774,358 (teaches rules checking using testcases); U.S. Pat. No. 4,763,289 (teaches creating a testcase sing a fault simulator); U.S. Pat. No. 6,226,716 (teaches designer generated testcases); U.S. Pat. No. 5,815,688 (teaches testing and verifying cache accesses on an out-of-order computer system using testcases); U.S. Pat. No. 5,724,504 (teaches determining an amount of coverage provided by a set of testcases); U.S. Pat. Nos. 5,703,788 and 5,631,857 (teach evaluating testcase effectiveness); and U.S. Pat. No. 4,527,249 (teaches designing a simulator to quickly run a large number of testcases), the complete disclosures of which are herein incorporated by reference. However, none of these or other conventional systems provide a manner of organizing testcases into one library, or having the testcases take into account design specific options such as back end of the line (BEOL) metal stacking options for a semiconductor process.
Therefore, there is a need for a new and improved system and methodology for automatically creating testcases (testcase files) for design rule checking for all variations of a technology quickly, efficiently, and accurately. Moreover, there is a need for a new and improved system and methodology for automatically creating testcases for design rule checking which organizes the testcases into one library having a plurality of root cells, and having the testcases take into account design specific options such as back end of the line (BEOL) metal stacking options.
In view of the foregoing and other problems, disadvantages, and drawbacks of the conventional generation and verification systems and techniques, the present invention has been devised, and it is an object of the present invention to provide a system and method for automatically creating testcases for design rule checking. Another object of the present invention is to provide a novel methodology for automatically verifying design rule checking runsets. Still another object of the present invention is to provide enhancements to the conventional Shapediff program. Yet another object of the present invention is to provide a system that will allow to not only check for unintentional fails and unintentional passes in the verification process, but will also utilize information extracted from the design manual to ensure that every rule in a manual is coded. It is still another object of the present invention to provide a methodology such that even if no testcase exists for a particular ground rule, then the system is still able to provide such information to the user. Another object of the present invention is to use both the testcases and a list of ground rules extracted from a manual to guarantee that there is code coverage for every rule.
In order to attain the objects suggested above, there is provided, according to one aspect of the invention, a novel system and methodology for verifying design rule checking runsets comprising automatically creating testcases, organizing the testcases such that there is one library with a plurality of root cells, running the design rule checking runset against the testcases; and allowing the testcases to take into account any design specific options, such as back end of the line stack metal options.
More specifically, according to the present invention, a novel method is disclosed for automatically creating testcases for design rule checking comprising the steps of first creating a table with a design rule number or identifier, a description, and the values from a design rule manual. Next, any design specific options are derived that affect the flow of the design rule checking, including back end of the line metal stack options. Then, the design rule values and any design specific options (including back end of the line metal stack options) are extracted into a testcase evaluator. The next step is to organize the testcases such that there is one library with a plurality of root cells. There is one root cell for checking all rules pertaining to the front end of the line and multiple root cells for checking design specific options including back end of the line stack options. The final step of the process involves running the DRC runset against the testcases to determine if the DRC runset provides for design rule checking.
There are several benefits of the present invention. For example, the present invention provides a novel methodology for automatically verifying design rule checking runsets. Moreover, the present invention provides enhancements to the conventional Shapediff program that will allow it to not only check for unintentional fails and unintentional passes, but will also enable it to use information extracted from the design manual, to ensure that every rule in the manual is coded. Another benefit of the present invention is that if no testcase exists for a particular ground rule, then the enhanced Shapediff program is able to provide such information to the user, which is not available in the conventional Shapediff methodology. Furthermore, according to the improvements provided by the present invention, the enhanced Shapediff 160 uses both the testcases and a list of ground rules extracted from a manual to guarantee that there is code coverage for every rule.